Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Match privateKey type in both JwtModuleOptions and JwtSignOptions #1192

Closed

Conversation

david-a
Copy link

@david-a david-a commented Jan 31, 2023

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

Dynamically sending a privateKey to jwtService.sign() (as opposed to using the JwtModule config) does not support passphrase encoded types (inconsistency in the Typescript interface).

Issue Number: N/A

What is the new behavior?

JwtSignOptions now supports passphrase encoded private key (using jwtService.sign()).

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

jwt.Secret type includes string | Buffer as well as { key: string | Buffer; passphrase: string }.
This change is required in order to enable using a {key,passphrase}-structured privateKey in jwtService.sign() calls like it does in JwtModule.register().
The use case is when you want to dynamically provide such key to the sign method (e.g. when each user/token has a different key pair).

@david-a david-a changed the title Match privateKey type in both JwtModuleOptions and JwtSignOptions fix: Match privateKey type in both JwtModuleOptions and JwtSignOptions Jan 31, 2023
@kamilmysliwiec
Copy link
Member

Fixed in this PR #1147

Thanks for your contribution anyway!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants